The following information provides a basic explanation of the TELNET protocol and related concepts. See the Assembly Overview for information on using the classes in this library.
TELNET (Telecommunications Network Protocol) is a data communications protocol that provides a set of rules for communication between computers. Telnet communication is the same for all systems and therefore works between different types of computers and operating systems. Many host systems support Telnet, and it is often used for remote login where one computer is accessed from another. A typical Telnet application would use the protocol to move data between a terminal emulator and a UNIX server (host).
Telnet is mainly used for online terminal communications - the user logs in to remote machines and issue commands as if he were actually at these machines. Telnet can also be used to access remote databases, control other computers, distribute work among multiple systems, and remotely execute many applications.
Telnet is built upon TCP and provides additional features that make it an upper-layer protocol. Typically, a terminal sends commands to a host, and the host responds with messages or data. For example, a user may type "help" and the remote host may respond with "Type a command to get help on."
Telnet provides option negotiation as a means for establishing conventions between two machines. During a session, either host may send the other a command to request or volunteer a specific option. For example, the echo option may be negotiated.
Connections are made to a port and host name or address. Most Telnet connections are made to the standard port 23. All computers on a network have a distinguishing IP address. Standard IPv4 addresses have the following same format:
nnn.nnn.nnn.nnn
where each nnn is a number from 0 to 255 (except for the first octet, which may be from 0 to 247). This means an IPv4 address is 32bits long, allowing nearly 2^32 unique values. A typical IP address might be 129.229.1.2.
PowerTCP provides full support for IPv6. IPv6 was established as the next generation Internet protocol, in order to greatly increase the number of available IP addresses. IPv6 addresses have the following hexadecimal format:
xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
where each xxxx is a hex value from 0000 to FFFF (0 to 65535). An IPv6 address is 128bits long, allowing 2^128 unique values. A typical address might be fe80::211:d800:97:c915. Note that "::" indicates a consecutive group of 0 values.
Most networks also support computer names, where the network will translate a name (such as "server3") into an IP address.
The Network Virtual Terminal (NVT) is a Telnet concept used to represent both hosts in a connection. The NVT is an imaginary character-based device with a keyboard and a printer (input and output). Incoming data goes to the printer, and input from the keyboard goes to the other end of the Telnet connection. Both ends of a Telnet connection must support the NVT.
The NVT supports the 7-bit character set known as NVT ASCII. NVT ASCII is the same as normal ASCII text, except that only 7 bits represent the character. The eighth high bit of the byte must be set to 0. In NVT ASCII, an end of line is represented by a two-character sequence CR, LF (carriage return, line-feed).
Both ends of a Telnet connection map their own terminal device characteristics to and from the NVT. For example, a program must change all 8-bit ASCII characters to the NVT character set. The NVT is intended to strike a balance between being overly restrictive (not providing some computers a rich enough vocabulary for mapping into their local character sets) and being overly inclusive (penalizing users with modest terminals).
Please refer to RFC 854 for more information on the NVT.
PowerTCP provides full support for binary data transmission. The following basic Telnet encoding rules are applied when sending:
For all data received, the reciprocal transformation takes place within the Telnet component. This mechanism, established by RFC 854, enables the transmission of 8-bit binary data over a single Telnet channel.
There is also a TransmitBinary option that can be easily set using the Binary property of the Telnet component. When set to RequestOn, the TransmitBinary option is negotiated for both directions. When in this mode, a naked CR is not padded with a following NULL when data is sent. When data is received, any CR NULL encountered is used unaltered. All other padding (such as the doubling of IAC bytes) remains the same.
Option negotiation is the process by which two computers agree on the features they will or will not provide. Each computer may send and respond to commands. A typical option negotiation session may occur as follows (although over 40 different options might be negotiated):
| Computer A | Computer B |
|---|---|
| 1. I will echo back what you send to me. | |
| 2. OK, Do echo back what I send to you. | |
| 3. Do suppress go–aheads. | |
| 4. No, I won't suppress go–aheads. |
Either machine may initiate option negotiation. One machine may request that the other machine support or not support an option, or inform the machine that it will or won't support an option. The other may then respond that it will or won't support an option, or request that the other computer support or not support an option. The following table describes the four option negotiation commands:
| Command | Description |
|---|---|
| WILL | The sender wants to support the option |
| WONT | The sender will not support the option |
| DO | The sender wants the receiver to support the option |
| DONT | The sender wants the receiver to not support the option |
The different pairs of commands and responding commands follow:
| Command | Response | Option Used |
|---|---|---|
| WILL I will support this option |
DO I do support this option |
Yes |
| WILL I will support this option |
DONT No, don't support it |
No |
| WONT I won't support this option |
DONT OK, don't support it |
No |
| DO Do support this option |
WILL OK, I will support it |
Yes |
| DO Do support this option |
WONT No, I won't support it |
No |
| DONT Don't support this option |
WONT OK, I won't support it |
No |
Note If a machine does not want an option supported (WONT/DONT), the other machine must comply, responding with a DONT or WONT.
Telnet also provides suboption negotiation—negotiating details about a specific option. An example is the "terminal type" option. For both computers to decide to support the same terminal type, instead of using a different option for each individual terminal type, a suboption is negotiated. A typical suboption negotiation is shown below:
| Computer A | Computer B |
|---|---|
| 1. I will support different terminal types. | |
| 2. OK, Do support different terminal types. | |
| 3. OK, send your terminal type suboption. | |
| 4. My terminal type suboption is "IBMPC". |
Option negotiation and suboption negotiation makes Telnet very flexible and adaptable to many different terminal configurations. Refer to the applicable RFCs for more information on Telnet and Telnet option negotiation.